With the development in communication technology, multiple communication interface devices become widely available and deployed. For example, a laptop computer would have Ethernet, Wireless Local Area Network (WLAN) and Bluetooth interfaces, and a handheld device would have both WLAN and cellular interfaces. Usually an application session can make use of several or all of these interfaces on a device, e.g. during a mobile handover, or when multi-homing is used. It is also possible that the communication peer is a multi-interface device. In this case, a method to discovery the peer relationship and identify each other is required for a successful communication.
Traditionally, a device identifies its peer with the link address, e.g. IP (Internet Protocol) address, Media Access Control (MAC) address, etc. However, this method is not workable with the multiple link case. When both peers have multiple links interconnected, using one link address cannot properly represent the relationship between the links. For example, as depicted in FIG. 1, Network Entity A (101) has multiple links connected to the Network Entity B (102), e.g. Link 1 (111) to Link n (113). At the same time, Network Entity A (101) has multiple links connected to the Network Entity C (103), e.g. Link m (114) to Link k (115). In this case, referring to Network Entity B (102) with its link address on Link 1 (111) would cause confusion at Network Entity A (101). This is because for example, the Network Entity C (103) could use the same link address on Link m (114). Since Link 1 (111) and Link m (14) may be in different network domains, there is no way to prevent the same link address being used by different entities. The problem cannot be solved even with concatenating Network Entity A (101)'s own link address, because it may use the same link address on Link 1 (111) and Link 2 (112).
Using the link address to identify the peer faces another problem in this heterogeneous environment. As described before, the different links may use different technologies, and thus different address format would be utilized. For example, the link address utilized in a cellular network is different from that used in the WLAN. Therefore, using the link address will result in incompatible identifiers over different links. For example, Network Entity A (101) may not be able to decide if the entities behind Link 2 (112) and Link n (113) are the same, since different identifier formats are used.    [Patent Document 1] U.S. Patent Publication 20040236855 A1    [Patent Document 2] U.S. Patent Publication 20040056890 A1    [Non-Patent Document 1] P. Jokela, et al, “Host Identity Protocol (HIP)”, Internet Draft: draft-ietf-hip-base-03.txt, Jun. 23, 2005    [Non-Patent Document 2] D. Eastlake, 3rd. P. Jones, “US Secure Hash Algorithm 1 (SHA1)”, RFC3174, September 2001
There are some existing efforts to solve the multiple link related problem. One of the solutions is the Internet Engineering Task Force (IETF) Host Identity Protocol (HIP) Working Group proposals (the above Non-Patent Document 1). In the Non-Patent Document 1, the protocol provides a method of separating the end-point identifier and locator roles of IP addresses. Hence, a terminal may be uniquely identified using its Host Identifier, but may still be reachable via its multiple IP addresses. However, the HIP is meant as an end-to-end solution, and not efficient for a peer-to-peer scenario. The HIP requires 4 messages change processes, puzzle computation, and a solution between the 2nd and 3rd initialization packets. What is more, the HIP requires the support of a directory query, e.g. DHCP, which may further impact efficiency for a peer-to-peer solution. Besides the above, the IP centric design of the HIP also makes it not apply to the scenarios where only layer 2 is available between the peers.
There is also Multi-link tunneling described in the above Patent Document 1 as another solution. This Multi-link tunneling uses tunnel device to implement Virtual Private Network (VPN) services with upper layer transparency of multi-homing via multiple routes. However, this solution uses the IP address to identify the links, which is again not applicable for those layer 2 only links. The solution also does not apply to heterogeneous media and multiple security procedures. Therefore, it does not solve the problems in environment depicted in FIG. 1.
Another attempt for solving the problem is presented in the above Patent Document 2. In this solution, client's signature is used to identify the remote node that is in communication with itself. Obviously, this solution requires the client signature be available for each possible communication peer, which is impossible for two new nodes. The solution also specifies Extensible Markup Language (XML) as storage format, which is higher layer information that may not be proper for lower layers, e.g. Layer 2. This solution also does not fully address the security issue, and only the identification is provided.